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This document specifies Distributed XML-Query (DXQ), a method to query 
distributed XML-databases and XML-representations via a central interface. 

W3C's XML-Query language [l a offers a powerful instrument for information 
retrieval on XML repositories. Here we describe an implementation of this re- 
trieval in a real world's scenario. Distributed XML-Query processing reduces 
load on every single attending node to an acceptable level. The network al- 
lows every participant to control their computing load themselves. Furthermore 
XML-repositories may stay at the rights holder, so every Data-Provider can 
decide, whether to process critical queries or not. If Data-Providers keep redun- 
dant information, this distributed network improves reliability of information 
with duplicates removed. 
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1. Architecture 



Every Distributed XML-Query Network (DXQ-Network) consists of at least one XML-Query 
Distributor and at least one XML-Document Provider. The XML-Document Provider places 
an XML document [3] at the DXQ-Network's disposal. The XML- Query Distributor enables 
the simultaneous execution of XML-Queries [2] on all XML-repositories in the DXQ-Network 
and aggregates the individual XML-Query results. The DXQ-Network is being used via a 
DXQ- Client interface. 

Any instance within the DXQ-Network such as DXQ-Client, XML-Document Provider, 
and XML-Query Distributor, is a DXQ-Node. 

1.1. XML-Document Provider 

The XML-Document Provider (XDP) is the instance exporting its XML-database or XML- 
representation into the DXQ-Network. It offers an interface to receive XML-Queries from 
the DXQ-Network to be executed on the exported XML-document. The query result will 
be serialized to XML [2| and returned to the XQD. 

1.2. XML-Query Distributor 

The XML-Query Distributor (XQD) is the instance offering an interface to receive XML- 
Queries from DXQ-Clients. The XQD distributes the XML-Queries to the XDPs in the 
DXQ-Network. It also collects and joins the query-results. To join the results, the XQD 
uses an algorithm (see section |3] on page EI) being specified by the DXQ-Client. The XQD 
sends the joined results as the result of the received XML-Query back to the DXQ-Client. 

Those XDP which receive XML-Queries from the XQD are listed in the Distribution List. 
To be listed, the XDPs have to register themselves. The XQD also offers an interface for 
the registering communication with XDPs fsee l2.6.T1 on pagell(J|). 

1.3. DXQ-Client 

The DXQ-Client is the instance sending XML-Queries into the DXQ-Network and specifying 
algorithms for joining result sets by the XQD. 

2. Distributed XML-Query Protocol 

The Distributed XML-Query Protocol (DXQP) is the basis for every communication between 
the DXQ-Nodes. This protocol is case sensitive and characters must 1 be UTF-8 [HI encoded. 

2.1. Transport 

The transportation method of the DXQP-messages between the DXQ-Nodes is implemen- 
tation depending. 



1 Words like 'may', 'must', 'should' are always meant in terms of RFC 2119. 
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Example HTTP: The transport of the DXQP-messages can be implemented by using 
(S)HTTP. For this all XQDs and XDPs have to implement their own HTTP-Server of 
course or be bound to an external server. The DXQ-Client connects an XQD (or the 
XQD connects an XDP) by sending an HTTP-POST-message (or GET-message, which is 
not recommended by the authors of the document) to the corresponding web-server. The 
message contains the DXQP-message in its body. Host, port and path information of the 
querying DXQ-Node are derived from the Identifier of the node. In this case the Identifier 
is an URL (see also: 12.2(1 . The web-server responds with the DXQP-reply-message in the 
body of an HTTP-message. 

Example TCP: TCP can also be used for transport directly by opening separated ports 
bound to the nodes in the DXQ-Network. The Identifier of each DXQ-Node contains the 
port-information (e.g. dxqp : //physnet . isn-oldenburg. de : 8750/). Those of the DXQ- 
Nodes initiating the communication, open channels to the port and send DXQP-messages. 
The communication accepting DXQ-Nodes respond with DXQP-messages. The communi- 
cation channel may be kept open and can be reused for sending queries to reduce commu- 
nication overhead. 

2.2. Name and Identifier of a DXQ-Node 

The Name is a string describing any DXQ-Node in a user-friendly way. The Name should 
be unique within the DXQ-Network. The Name may contain every character apart from 
<CRLF>, {, and }. The Identifier is used for unique identification of any DXQ-Node within 
the DXQ-Network. 

NODE-NAME : := [any character sequence not containing 
<CRLF>, '{' or '>'] 
NODE-IDENTIFIER ::= (URL | "") 

For any XQD and XDP the URL j^j of the interface of the specific DXQ-Node is used as the 
Identifier (e.g. http://physnet.isn-oldenburg.de/dxq-xdp/ or dxqp : //physnet . isn- 
oldenburg. de: 8750/). The DXQ-Client uses the empty string as its Identifier, until an 
Identifier is assigned to the DXQ-Client by the XQD. The assigned Identifier is passed 
within the header variable Msg-To of the first message transferred from the XQD to the 
DXQ-Client as a reply to the empty string in the header variable Msg-From in the for- 
mer message (see also: 12.3(1 . The Identifier has to be a valid URL and unique for the 
DXQ-Client and the XQD. The following examples are valid Identifiers: http : //a6bf 278d, 
http : //134 . 106 . 31 . 210/ab6bf 278d or http : //134 . 106 . 31 . 210/?sessid=a6bf 278d. 

2.3. Structure of a DXQP-Message 

Every DXQP-message consists of a header and a body. The two parts are separated 
by <CRLF>. The header consists of the message's ID-LINE and several header variables. 
The body of the message has to contain the number of bytes given in the header variable 
Content-Length. If Content -Length is empty or not a positive integer, the message will 
end with the <CRLF> closing the header part. 
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The general grammar for any DXQP-message is: 



MESSAGE 
HEADER 
ID-LINE 
VERSION 
MSGTYPE 



VARIABLE 
VNAME 
VVALUE 
<CRLF> 
BODY 



= HEADER <CRLF> BODY 

= ID-LINE <CRLF> (VARIABLE)* 

= "DXQP-" VERSION " " MSGTYPE 

= [0-9] "." [0-9] 

= ("OK" | "ERROR" I 

"XML-QUERY" | "MERGE-ALGORITHM" | 

"XML-QUERY-RESULT" | "XML-QUERY-MERGED-RESULT" 

"REGISTER" | "UNREGISTER" | 

"ADDTODL" | "RMFROMDL" | 

"INFO-REQUEST" | "INFO-REPLY") 
= VNAME " : " ( " " ) + VVALUE <CRLF> 
= [A-Za-z-]+ 

= [any byte sequence not containing <CRLF>~\ 
= OxOD OxOA 

[any byte sequence] 



The number, meaning and content of header variables in a message are implementation 
depending. Header variables in this document are given as examples only, but implementa- 
tions should not use variables with identical names but different semantics. This applies to 
the already defined variable Content -Length as well as to Msg-From and Msg-To. 

The header variable Msg-From gives the Identifier of the DXQ-Node sending the message. 
Msg-To gives the Identifier of the DXQ-Node receiving the message. Without a valid Iden- 
tifier (see also: 12.21 on the preceding page) in any of these variables the complete message 
becomes invalid. 



VAR-Msg-From 
VAR-Msg-To 
VAR-Content-Length 



= "Msg-From: " NODE-IDENTIFIER <CRLF> 
= "Msg-To: " NODE-IDENTIFIER <CRLF> 
= "Content-Length: " [0-9]+ <CRLF> 



2.4. DXQP-1.0 Messages 
2.4.1. OK 

The OK-message gives a positive acknowledgment. 

MSG-OK ::= "DXQP-1.0 OK" <CRLF> 

VAR-Msg-From VAR-Msg-To 
(VAR-Transaction-ID) ? 
<CRLF> 

The header variable Transaction-ID is exclusive and mandatory for responses on XML- 
QUERY- messages only (see also: 12. 4. "51 on the next page and section 0.6.31 on page^J). 



2.4.2. ERROR 

The ERROR-message gives a negative acknowledgment and reports of errors. This message 
has to comprise the header variable Error-Code giving the value of the error-code as defined 
in 12. 51 on page EH The body of the message may contain further error information. 
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MSG-ERROR ::= "DXQP-1 . ERROR" <CRLF> 
VAR-Msg-From VAR-Msg-To 
VAR-Error-Code 

(<CRLF> | (VAR-Content-Length <CRLF> BODY)) 
VAR-Error-Code : := "Error-Code: " ERROR-CODE <CRLF> 
ERROR-CODE ::= [0-9] {3} 



2.4.3. XML -QUERY 

The XML-QUERY-message provides an XML-Query in its body for execution by the receiving 
DXQ-Node. If this message is sent to an XQD it has to comprise the header variable 
Merge-Algorithm. 

The header variable Transaction-ID gives a VVALUE arbitrarily chosen by the sender of 
the message to allow unique identification of this message in the context of multi-query 
processing. The Transaction-ID must not contain any white spaces. 

MSG-XML-QUERY ::= "DXQP-1. XML-QUERY" <CRLF> 

VAR-Msg-From VAR-Msg-To 

VAR-Transaction-ID (VAR-Merge-Algorithm) ? 
VAR-Content-Length <CRLF> XML-QUERY 
= "Transaction-ID: " TRANSACTION-ID <CRLF> 
= I any VVALUE not containing " "] 
= "Merge-Algorithm: " MALG-SPEC <CRLF> 
= [a-zO-9-] 



VAR-Transaction-ID 
TRANSACTION-ID 
VAR-Merge-Algorithm 
MALG-SPEC 



2.4.4. MERGE-ALGORITHM 

After the DXQ-Client sent an XML-QUERY-message to the XQD giving "user-defined" in 
Merge-Algorithm, it has to send the MERGE-ALGORITHM-message, giving an XML-Query in 
its body to join the query-results of the single XDP in the DXQ-Network. 

The header variable Transaction-ID has to provide the same value as given in the cor- 
responding XML-QUERY-message. 

MSG-MERGE-ALGORITHM : := " DXQP- 1.0 MERGE-ALGORITHM" <CRLF> 

VAR-Msg-From VAR-Msg-To 
VAR-Transaction-ID 

VAR-Content-Length <CRLF> XML-QUERY 



2.4.5. XML-QUERY-RESULT 

The XML-QUERY-RESULT-message is the answer to an XML-QUERY-message. It is sent from 
every XDP to the XQD. The serialized query result is given in the body of this message. The 
header variable Transaction-ID has to give the same value as given in the corresponding 
XML-Query-message. 

MSG-XML-QUERY-RESULT ::= "DXQP-1 . XML-QUERY-RESULT" <CRLF> 

VAR-Msg-From VAR-Msg-To 
VAR-Transaction-ID 

VAR-Content-Length <CRLF> XML-DOCUMENT 
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2.4.6. XML-QUERY-MERGED-RESULT 

The XML-QUERY-MERGED-RESULT-message is the answer to the XML- QUERY-message . It is 
sent from the XQD to the DXQ-Client. The serialized joined result of the corresponding 
query is given in the body of the message. The header variable Transaction-ID has to 
give the same value as given in the corresponding XML-Query-message. The header variable 
Result-Sources should contain a list of Names of those XDPs which delivered parts of the 
result set. 

MSG-XML-QUERY-MERGED-RESULT : : = 

"DXQP-1.0 XML-QUERY-MERGED-RESULT" <CRLF> 
VAR-Msg-From VAR-Msg-To 
VAR-Transact ion-ID VAR-Result-Sources 
VAR-Content -Length <CRLF> XML-DOCUMENT 
VAR-Result-Sources : := 

"Result-Sources: " ("{" NODE-NAME "} ")* 

"{" NODE-NAME "}" <CRLF> 

2.4.7. REGISTER 

By sending the REGISTER-message, the XDP registers itself at the XQD. 

MSG-REGISTER : := "DXQP-1 . REGISTER" <CRLF> 

VAR-Msg-From VAR-Msg-To 
VAR-Node-Name 
<CRLF> 

VAR-Node-Name : := "Node-Name: " NODE-NAME <CRLF> 

2.4.8. UNREGISTER 

By sending the UNREG I STER-message, the XDP checks out from the XQD. 

MSG-UNREGISTER ::= "DXQP-1 . UNREGISTER" <CRLF> 

VAR-Msg-From VAR-Msg-To 
<CRLF> 

2.4.9. ADDTODL 

The ADDTODL- message is used by the XDP to sign in to the Distribution List of the XQD. 
The XQD will distribute queries to those XDPs listed in the Distribution List only. 

MSG-ADDTODL ::= "DXQP-1.0 ADDTODL" <CRLF> 
VAR-Msg-From VAR-Msg-To 
<CRLF> 

2.4.10. RMFROMDL 

To sign off the Distribution List of the XQD, the XDP sends the RMFROMDL-message. 

MSG-RMFROMDL ::= "DXQP-1.0 RMFROMDL" <CRLF> 

VAR-Msg-From VAR-Msg-To 
<CRLF> 
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2.4.11. INFO-REQUEST 



To get information about an XQD or XDP, every DXQ-Node can send the INFO-REQUEST- 
message. The header variable Request contains a list of inquired information. To inquire 
a sign of life only, the header variable Request may be empty. INFO-NAME is described 
in 12.4.121 in more detail. Instead of the detailed list of information, the Request variable 
can also contain "*" to ask for all information available. 

MSG-INFO-REQUEST ::= "DXQP-1.0 INFO-REQUEST" <CRLF> 

VAR-Msg-From VAR-Msg-To 
VAR-Request 
<CRLF> 

VAR-Request : := "Request: " 

("*" | (INFO-NAME " ")* INFO-NAME)? <CRLF> 



2.4.12. INFO-REPLY 



The INFO-REPLY-message is the answer to the INFO-REQUEST-message. This message con- 
tains all of the requested information in the corresponding header variables. 



MSG-INFO-REPLY 



VAR-INFO 
INFO-NAME 
INFO-VALUE 
YESNO 
MALG-LIST 
XDP-LIST 
XDP-SPEC 
TRANSACTION-ID-LIST 



"DXQP-1.0 INFO-REPLY" <CRLF> 
VAR-Msg-From VAR-Msg-To 
(VAR-INFO)* 
<CRLF> 

INFO-NAME ": " INFO-VALUE <CRLF> 

VNAME 

VVALUE 

("yes" | "no") 

((MALG-SPEC " ")* MALG-SPEC)? 
((XDP-SPEC " ")* XDP-SPEC)? 
(NODE-IDENTIFIER)? "{" NODE-NAME "}" 
((TRANSACTION-ID " ")* TRANSACTION-ID)? 



Meaning and Values of INFO-NAME are implementation depending. Several INFO-NAMEs 
are pre-defined with this specification. If an INFO-REQUEST asks for an INFO-NAME which is 
not supported by the specific implementation, an empty value, not an error will be returned 
in INFO-REPLY. 

Here several INFO-NAMEs are pre-defined, in parentheses the name of the grammar-pro- 
duction of the value in the INFO-REPLY-message is given. 

Node-Name (NODE-NAME) 

Name of the DXQ-Node (see also: 12.21 on pageE}. 

Admin (VVALUE) 

Information on the administrator of the DXQ-Node (name, email, etc.) 
Registered (YESNO) 

The value of this variable will be "yes", if it is asked by an XDP to an XQD and the 
XDP is registered at the XQD. Else the value will be "no". 
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Is-in-DL (YESND) 

The value of this variable will be "yes", if it is asked by an XDP to an XQD and the 
XDP is listed in the Distribution List of the XQD. Else the value will be "no". 

Merge-Algorithms (MALG-LIST) 

Delivers a list of implemented merging algorithms (including the mandatory algorithm 
user-defined). If the DXQ-Node to be asked is not an XQD, the value delivered by 
this variable will be the empty string. 

Registered-XDPs (XDP-LIST) 

Delivers a list of registered XDPs. It is optional to support this information. 

Active-XDPs (XDP-LIST) 

Delivers the list of XDPs from the Distribution List. It is optional to support this 
information. 

Active-Queries (TRANSACTION-ID-LIST) 

Delivers a list of the Transaction-IDs initiated by the DXQ-Node being asking and 
still in progress at the DXQ-Node to be asked. The list must only contain those 
Transaction-IDs processed under the same Identifier as those of the INFO-REQUEST- 
message. It is optional to support this information. 

2.5. DXQP-1.0 Error-Codes 

[100] Invalid message 

The ID-LINE, the name of one of the header variables or the Identifier in the header 
variable Msg-From or Msg-To is invalid. 

[101] Unexpected message 

The message was not expected in the current context (e. g. REGISTER sent to an XDP), 
although it has the correct syntax. 

[102] Missing header variable 

The message lacks of at least one header variable, essential for the current context of 
the message. The body of this message contains the name of the missing variable. 

[103] Missing content 

Though it is essential for processing, the body part of the message is missing (e. g. in 
an XML-Query- message). 

[200] XML-Query processor error 

The XML-Query processor /interpreter gave an error. The body of this message con- 
tains the original error-message from the processor/interpreter. 

[300] Unsupported merge algorithm 

The XQD does not support the merging algorithm specified in the header variable 
Merge-Algorithm of an XML-QUERY-message. 
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[400] No XML document providers available 

If the Distribution List of an XQD is empty, this ERROR-message will be replied on 
XML- QUERY- messages . 

[500] Internal error 

An internal error occurred when processing the message. 

[9xx] Implementation-defined error 

All 9xx error codes are reserved for implementation defined error-codes. 

2.6. Communication 

Here the semantics of the DXQP-messages within several contexts are described. 
2.6.1. XQD and XDP (Control) 

Register: Communication is initiated by sending a REGISTER-message from the XDP to 
the XQD. If the XDP was registered at the XQD, the XQD replies the OK-message, else the 
ERROR-message will be replied. 

When sending the UMREGISTER-message, the XQD removes the corresponding XDP from 
the list of registered XDPs and replies with the OK-message. In case of an error during 
processing the UNREGISTER-message, the ERROR-message will be sent. To leave the undefined 
registration status, the XDP may use the INFO-REQUEST-message. 

The period between REGISTER-OK and UNREGISTER-OK is called a Session. 





REGISTER 






OK | ERROR (Communication closed) 




XQD 


(Session) 


XDP 


UNREGISTER 




OK | ERROR 











Figure 1: REG I STER- /UNREG I STER- Communication 



Distribution List: Every XQD runs a list of registered XDPs, which will get XML-Queries 
in the distribution process. XDPs have to sign themselves into this Distribution List explic- 
itly. 

To sign into the Distribution List, the XDP sends the ADDTODL-message to the XQD. The 
XQD will answer either with the OK- or with the ERROR-message. 

To verify the status of the Distribution List, the XDP should use the INFO-REQUEST- 
message frequently (see also: l2.4.TT1 on pagelHJ). 
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The XDP may sign off from the Distribution List (e. g. to reduce the server load in critical 
situations) by sending the RMFROMDL-message to the XQD. The XQD will reply with an 0K- 
message. In case of an error the ERRQR-message will be sent. To request its own status in 
the Distribution List, the XDP should use the INFO-REQUEST-message. 











ADDTODL 






OK | ERROR 




XQD 




XDP 


RMFROMDL 




OK | ERROR 

















Figure 2: Sign into and sign off the Distribution List 



Connectivity Care: Every XQD should send INFO-REQUEST-messages with empty Request- 
variable to all registered XDP in regular intervals. Every XDP has to reply with an INFO- 
REPLY- message. In case of no reply message, a time-out, or an ERROR-reply, the XQD should 
remove the corresponding XDP from the Distribution List. 

After removing an XDP from the Distribution List, an XQD may still send INFO-REQUEST- 
messages to the still registered XDPs. In the case of repeated time-outs the XQD may 
unregister the XDP. 

Every XDP may send INFO-REQUEST-messages to verify being registered and signed into 
the Distribution List. After being removed from the Distribution List or unregistered, the 
XDP may register and sign in again. 



XQD 




XDP 


INFO-REQUEST 


INFO-REPLY | ERROR 







Figure 3: Ping via INFO-REQUEST and INFO-REPLY 
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2.6.2. XQD and XDP (Data) 



Every XDP listed in the Distribution List of an XQD gets XML-QUERY-messages which con- 
tain the XML-Queries to be processed on the XML-Document, XML-Database or XML- 
Representation. The XDP will reply an XML-QUERY-RESULT- or an ERROR-message. 

If the XML-Query succeeds, the XML-QUERY-RESULT-message will reply in its body part 
the result of the XML-Query executed. In case of any error during the processing of the 
XML-Query, the ERROR-message will be replied giving the respective Error-Code. The 
error-message of the XML-Query processor should be given in the body part of the ERROR- 
message. 



XQD 


XML -QUERY 


XDP 


XML-QUERY-RESULT | ERROR 





Figure 4: Datatransfer between XQD and XDP 



2.6.3. DXQ-Client and XQD (Data) 

The DXQ-Client (user) initiates the communication by sending the XML-QUERY-message to 
the XQD. This XML-QUERY-message contains the XML-Query to be processed by the XDP 
in its body. The further communication depends on the value of the header variable Merge- 
Algorithm of this message. 

If the value of the header variable Merge-Algorithm is user-defined, then the XQD 
will reply an OK-message and will wait for the MERGE-ALGORITHM-message to be sent by the 
DXQ-Client. All messages of this query handling (XML-QUERY-message, OK-message, MERGE- 
ALGORITHM-message) have to give the same value in the Transaction-ID header variable, 
to allow unique assignment of the messages. 

If the value of the header variable Merge-Algorithm is not user-defined, then the XQD 
will reply the XML-QUERY-MERGED-RESULT-message directly, joined with the selected of the 
pre-defined algorithms (see also: section |3] on the next page). 

In the case of any error while processing the XML-Query, the XQD sends the ERROR- 
message, which closes the communication. 

The DXQ-Client sends the MERGE-ALGORITHM-message with the XML-Query in its body 
to join the result sets. For further information see also section |3] on the following page. 
With the OK-message message the DXQ assigns an Identifier to the DXQ-Client within the 
Msg-To header variable. This Identifier has to be used in the further communication, for 
example in the Msg-From header variable of the MERGE-ALGORITHM-message. 

The XQD will reply the XML-QUERY-MERGED-RESULT- message, which contains the joined 
result in its body. In the case of an error, the XQD replies the ERROR-message. If only some 
but not all of the XDP reply ERROR-messages, the XQD should process the available results. 
The header variable Result-Sources lists those XDPs only which delivered data for the 
joined result. In case of all XDPs replying an ERROR-message, the XQD will also reply an 
ERROR-message. 
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Client 


XML-QUERY (pre-defined algorithm) 


XQD 


XML-QUERY-MERGED-RESULT | ERROR 







XML -QUERY (user-defined) 






OK | ERROR (Communication closed) 




Client 


MERGE-ALGORITHM 


XQD 




XML-QUERY-MERGED-RESULT | ERROR 











Figure 5: Data-transfer between DXQ-Client and XQD 



3. Merge-Algorithm 

To join the different results of the single XDPs, the XQD uses a Merge-Algorithm which is 
specified by the DXQ-Client in the XML-QUERY- message (see also: l'2.4.3l on page©. The DXQ- 
Client can ask the XQD for a list of available pre-defined merging algorithms by sending 
an INFO-REQUEST-message (see also: 12.4,111 on page|HJ). The resulting list of algorithms is 
implementation depending. 

Here two Merge- Algorithms are described in detail. While the concatenate-algorithm is 
mandatory for every XQD implementation, the remove-duplicates-algorithm is an exam- 
ple of an implementation depending, non-obligatory algorithm. 



concatenate 

The results of the XDPs are just sticked together and framed by a <result>-Tag. 

remove-duplicates 

Assuming the following pair of results was delivered by two XDPs: 



<solarsystem> 
<planets> 

<planet >Mer cury</planet > 
<planet >Venus</planet > 
<planet>Earth</planet> 
</planets> 
</ solarsystem> 



<solarsystem> 
<planets> 

<planet >Venus</planet > 
<planet >Earth</planet > 
<planet>Mars</planet> 
</planets> 
</solarsystem> 



The remove-duplicates-algorithm will join these results into: 

<solarsystem> 
<planets> 

<planet>Mercury</planet> 
<planet>Venus</planet> 
<planet >Earth</planet > 
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<planet>Mars</planet> 
</planets> 
</ solarsystem> 

The XML-document is copied down to a specified depth. All elements of this or higher 
depth are sticked together, duplicates are removed. To specify this critical depth, this 
algorithm reads the header-variable Depth. 

Every XQD has to support a mandatory user-defined algorithm. If selecting this al- 
gorithm, the DXQ-Client must send a MERGE- ALGORITHM- message to the XQD. This mes- 
sage contains an XML-Query which is able to join the results received from the XDPs 
together. (For detailed information on the communication between DXQ-Client and XQD 
see also: 12.6.51 on page^J) 

The XQD lists all XDP-results into the context-item to be processed with the user-defined 
merge- algorithm: 

<context-item> 
<result> 
<xdp> 

<name>ZDi :, -71/a/?7e</name> 
</xdp> 

<xqres>XML-Query Result </xqres> 
</result> 

</ context-item> 

The <xdp>-Tag can also contain further implementation depending information. XML- 
Query Result is the body of the XML-QUERY-RESULT-message as received from the specific 
XDP. 

The result of the merging process will be sent to the DXQ-Client within the XQD's 
XML-QUERY-MERGED-RESULT-message. 
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A. Changes 

August 25th 2003: 

• To prevent misunderstandings about the header variable Query- ID it has been re- 
named to Transaction-ID. 

August 29th 2003: 

• To protect the privacy of the XDPs the <ident> tag in the context item of the user- 
defined merge algorithm has been removed. Implementations may reinsert this tag 
if they want to publish the XDPs' Indentifiers. 

October 8th 2003: 

• The information Active-Queries (in INFO-REQUEST/lNFO-REPLY-messages) has been 
made optional. 

• The NODE-IDENTIFIER in the grammar production XDP-SPEC (used for the information 
Registered-XDPs and Active-XDPs) has been made optional. 

• A new header variable Node-Name has been inserted into the REGISTER-message passing 
the XDP's Name to the XQD. 
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B. Example: DXQP-Communication 



Here the communication within an example DXQ-Network is described. The DXQ-Network 
consists of one XDQ and two XDPs, both exporting the XML-document 

<document><a>5</ a></document> 

One DXQ-Client builds the interface of the DXQ-Network. 

First both XDPs register themselves at the XQD, being included into the Distribution 
List of the XQD: 2 

DXQP-1.0 REGISTERS 

Msg-From : http : / /physnet . isn-oldenburg . de/dxq-xdp/^ 
Msg-To : http : //metasearch. isn-oldenburg .de/dxq-xqd/^ 
Node-Name: PhysNet^ 

<— ' 

DXQP-1.0 OK^- 

Msg-From : http : //metasearch . isn-oldenburg . de/dxq-xqd/ 
Msg-To : http : //physnet . isn-oldenburg . de/dxq-xdp/^ 

DXQP-1.0 ADDTODL^ 

Msg-From : http : //physnet . isn-oldenburg . de/dxq-xdp/^ 
Msg-To : http : //metasearch . isn-oldenburg . de/ dxq-xqd/^ 



DXQP-1.0 OK^- 

Msg-From : http : //metasearch . isn-oldenburg . de/dxq-xqd/ <• 
Msg-To : http : //physnet . isn-oldenburg. de/dxq-xdp/ 



DXQP-1.0 REGISTERS 

Msg-From: http : //physnet-mirror . isn-oldenburg. de : 8080/dxq-xdp/ < 
Msg-To : http : //metasearch . isn-oldenburg . de/dxq-xqd/^ 
Node-Name: PhysNet (Mirror)^ 

«— = 

DXQP-1.0 OK^- 

Msg-From : http : //metasearch . isn-oldenburg . de/ dxq-xqd/ <-^> 
Msg-To : http : //physnet-mirror . isn-oldenburg . de : 8080/dxq-xdp/^ 

DXQP-1.0 ADDTODL^ 

Msg-From: http : //physnet-mirror . isn-oldenburg. de : 8080/dxq-xdp/ < 
Msg-To : http : //metasearch . isn-oldenburg . de/dxq-xqd/^ 

DXQP-1.0 OK^- 

Msg-From : http : //metasearch . isn-oldenburg . de/dxq-xqd/ 
Msg-To : http : //physnet-mirror . isn-oldenburg . de : 8080/ dxq-xdp/ 



= <CRLF> 
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Following, the XQD inquires information about the XDPs: 



DXQP-1.0 INFO-REQUEST^ 

Msg-From : http : //metasearch . isn-oldenburg . de/dxq-xqd/ 
Msg-To : http : //physnet . isn-oldenburg. de/dxq-xdp/ 
Request : Node-Name Admins 



DXQP-1.0 INFO-REPLY^ 

Msg-From: http : //physnet . isn-oldenburg. de/dxq-xdp/ 
Msg-To : http : //metasearch . isn-oldenburg . de/dxq-xqd/^ 
Node-Name: PhysNet^ 

Admin: Max Mustermann <admin@physnet . isn-oldenburg. de> 



DXQP-1.0 INFO-REQUEST^ 

Msg-From : http : //metasearch . isn-oldenburg . de/ dxq-xqd/ 
Msg-To : http : / /physnet-mirror . isn-oldenburg . de : 8080/ dxq-xdp/ 
Request : Node-Name Admins 

DXQP-1.0 INFO-REPLY^- 

Msg-From : http : / / physnet-mirror . isn-oldenburg . de : 8080/dxq-xdp/ 
Msg-To : http : //metasearch . isn-oldenburg . de/ dxq-xqd/^- 
Node-Name: PhysNet (Mirror) ^ 

Admin: Bert Beispiel <admin@physnet -mirror . isn-oldenburg. de>^- 

The DXQ-Client connects the XQD by sending an initial XML-Query: 

DXQP-1.0 XML-QUERY^ 
Msg-From: *-^> 

Msg-To : http : //metasearch . isn-oldenburg . de/ dxq-xqd/^- 
Transaction-ID: 0^- 
Merge-Algorithm: user-def ined^ 
Content -Length: 23^ 

let $a := ./a return $a 
DXQP-1.0 0K^ 

Msg-From : http : //metasearch . isn-oldenburg . de/dxq-xqd/ 
Msg-To: http://a6bf^ 
Transaction-ID: 0^ 
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The XQD distributes the XML-Query to all XDPs which are listed in the Distribution 
List. It also collects the results: 



DXQP-1.0 XML-QUERY^ 

Msg-From : http : //metasearch . isn-oldenburg . de/ dxq-xqd/- 
Msg-To : http : //physnet . isn-oldenburg . de/dxq-xdp/ 
Transaction-ID: 0^ 
Content -Length: 23^ 

let $a := ./a return $a 
DXQP-1.0 XML-QUERY-RESULT ^ 

Msg-From: http : //physnet . isn-oldenburg. de/dxq-xdp/^ 1 
Msg-To : http : //metasearch . isn-oldenburg . de/ dxq-xqd/^ 
Transaction-ID: 0^ 
Content-Length: 8^ 

<-^> 

<a>5</a> 



DXQP-1.0 XML-QUERY^- 

Msg-From : http : //metasearch . isn-oldenburg . de/dxq-xqd/ 
Msg-To : http : //physnet-mirror . isn-oldenburg . de : 8080/dxq-xdp/ 
Transaction-ID: 1^ 
Content -Length: 23^ 

let $a := ./a return $a 
DXQP-1.0 XML-QUERY-RESULT ^ 

Msg-From: http : //physnet-mirror . isn-oldenburg. de : 8080/dxq-xdp/ 
Msg-To : http : / /metasearch . isn-oldenburg . de/ dxq-xqd/^ 
Transaction-ID: 1-*-^ 
Content-Length: 8^ 

<a>5</a> 

The XQD receives the MERGE- ALGORITHM- message from the DXQ-Client and responds 
with the joined results: 

DXQP-1.0 MERGE- ALGORITHM^ 
Msg-From: http://a6bf^ 

Msg-To : http : //metasearch . isn-oldenburg . de/ dxq-xqd/^ 
Transaction-ID: 0^ 
Content-Length: 51<-^ 

*— ' 

let $r := <a>{sum( . /result/xqres/a) }</a> return $r 



DXQP-1 . XML-QUERY-MERGED-RESULT^ 

Msg-From : http : //metasearch . isn-oldenburg . de/dxq-xqd/ * 
Msg-To: http://a6bf^ 
Transaction-ID: 0^ 

Result-Sources: {PhysNet} {PhysNet (Mirror)}^ 
Content-Length: 9^ 

< — > 

<a>10</a> 
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Finally the XDPs send an UNREGISTER-message to be removed from the network: 



DXQP-1.0 UNREGISTER^ 

Msg-From : http : //physnet . isn-oldenburg . de/dxq-xdp/^ 
Msg-To : http : //metasearch . isn-oldenburg . de/ dxq-xqd/^ 



DXQP-1.0 OK^- 

Msg-From : http : //metasearch . isn-oldenburg . de/dxq-xqd/ 
Msg-To : http : //physnet . isn-oldenburg. de/dxq-xdp/ 



DXQP-1.0 UNREGISTER^ 

Msg-From: http : //physnet-mirror . isn-oldenburg. de : 8080/dxq-xdp/ 
Msg-To : http : / /metasearch . isn-oldenburg . de/dxq-xqd/^ 



DXQP-1.0 OK^ 

Msg-From : http : //metasearch . isn-oldenburg . de/dxq-xqd/ 
Msg-To : http : //physnet-mirror . isn-oldenburg . de : 8080/ dxq-xdp/ 
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